#896 well :( Should not be merged right?

@StefMa I'd like to use appcompats AlertDialogs, but @hzsweers and @Meisolsson don't

Ok, let us discuss 👍
@Meisolsson want to stay on the MaterialDialogLib without a reason.
@hzsweers want to stay on this lib because of:

We should be moving all the dialogs to material dialogs then. There are
features of it that don't exist in the appcompat's dialogs as well, such as
sensible widths on tablets and more customizability. I don't know who did
the original addition of it here, but I very much prefer them to
appcompat's.

So currently we don't need the "more features" which the MaterialDialog-Lib brings on. So, actually it is only overhead on source code.
Also, but this is my opinion, we don't need "more features" on dialogs. Dialogs are only "simple" information "things".
According to Design Guid Dialogs are:

Dialogs inform users about critical information, require users to make decisions, or encapsulate multiple tasks within a discrete process. Use dialogs sparingly because they are interruptive in nature. Their sudden appearance forces users to stop their current task and refocus on the dialog content. Not every choice, setting, or detail warrants interruption and prominence.

So currently we don't need the "more features" which the MaterialDialog-Lib brings on. So, actually it is only overhead on source code.

Run the app on a tablet and suddenly we do.

Look, this is not a discussion, we're not going to switch to it. It's not a discussion because we have already discussed it. In the future, please abide by the rules we've laid out in our CONTRIBUTING.md about infrastructure changes like this and discuss with us first before assuming anything. Especially considering this was already discussed and decided before.